COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	.require "let.pub[let,les]" source_file
C00017 00003	.area text lines 4 to height
C00028 ENDMK
C⊗;
.require "let.pub[let,les]" source_file;
.every heading(,%3{page!})
.area text lines 4 to height in 2 columns 2 apart;
.place text
.next page
.begin center select 3;
Proposed Demonstration of
an Editor-based
Operating System
.skip;
.select 1
John McCarthy
Professor of Computer Science
.end
.skip
.fi;
.indent 4,0;
We propose to develop a new kind of operating system that employs an
interactive display editor at the top level, rather than the traditional
one-line command interpreter, to provide
better control over computational processes.

Present operating systems are unnecessarily inconvenient in a variety of
ways, as discussed above.  They were lacking in systematic design to begin
with and have gotten worse as ad hoc features with ad hoc syntaxes have
been added.  We propose to design and implement a new kind of system that
will rectify the principal shortcomings outlined above.

The main premise of the project is that the proper environment for the
interactive user of a computer is a display editor.  This provides the
ability to re-edit both previous input and new output in order to generate
new input and also to file the output as desired.  Various other
improvements in editors and operating systems are planned.  Thus the goals
and approach that we will use include the following.

%3Display Editor.%1 The shell and interactive programs will be normally
operated out of a new advanced display editor.  Programs for which this is
not suitable will be able to control the interaction themselves.  The
editor and the operating system will be kept fully programmable.  Thus
anything a person can do interactively, he will be able to write programs
to do.  This means that all output seeable by a user must also be readable
by programs.  Interactive programs that use the display in a non-standard
way will be able to violate this condition.  System status information
will be maintained in editable files.

%3Command Language.%1 The command language will be a sugared programming language ---
in fact, sugared Lisp.  The user will have the full capability of Lisp in
compounding the basic operations into command programs, including macros
(called execs in IBMese), recursion, and conditional expressions.  In our
examples, we sugar the Lisp by using conventional functional notation, but
"command programs" will have Lisp internal notation format.  Whether they
will be represented as list structure isn't decided.  File operations,
compiling, etc. will be treated as functions, e.g. one will have
statements like

.once indent 4;
%2foo.bin := fortran(foo.for)%1

.once indent 0,0;
The function fortran then represents the effect of the Fortran compiler
and can be composed with other functions.  The Unix pipes provide for
composition of functions but in a non-standard syntax and make the curious
assumption that all functions are unary.  We will consider carrying this
functional idea to an extreme.  Namely, typing a single text character to
a text editor may be regarded as executing an assignment statement of the
form

.once nofill; indent 0,0;
∂1(1) ∂5%2file := insert(file,char,place)%1

.once indent 0,0;
Operations on files are also obvious candidates to be regarded assignment
statements and will be compoundable in such statements as

.begin nofill
∂4%2foo.bin,foo.error :=
∂8fortran(append(foo1.for,
∂9precompile(foo2.alg)))%1
.end

.once indent 0,0;
The requirement of programmability means that whatever compound operations
the user can do himself, he can conveniently make command programs do for
him.  Of course, it must be convenient to include conditionals in command
programs, and this is where most macro and exec systems fall down.
Conditionals are an afterthought and are done awkwardly.  Keeping the
command language programmable is to have a higher priority than making the
system controllable by the mouse.  Thus any control operations involving a
mouse are sugared versions of the basic language.

%3Chomsky Principle.%1 The command language, the editor language and any others
provided as part of the system will obey what may be called the "Chomsky
principle": the syntax never requires a constant at any point.  Chomsky
claimed in his "Reflections on Language" that human languages have this
property; some linguists dispute this.  Anyway we want it.  It will always
accept a term designating an entity of the required type.  Thus whereever
a file name is acceptable, a file-valued expression, e.g.  a file-valued
conditional expression, is also acceptable.  Many programming languages
have this property, but apparently no operating systems.

%3Sugaring.%1 The sugaring will be both syntactic and semantic.  Syntactically,
one will simply type the character while in a context in which typing the
character inserts it in the file.  Other operations will be sugared in
appropriate ways, e.g. one can write

.once nofill
∂4%2fortran(foo)%1

.continue
for the above assignment statement.

By semantic sugar we mean that in appropriate contexts, the operations
that are the most obvious interpretations of the base forms are not
carried out, but something easier is done.  For example, (1) above doesn't
make a new copy of the file, but merely inserts a character in the core
image of the file.

%3User Interface.%1 By editor-based, we mean that the user is always interacting
with the system via a powerful editor, e.g. something like EMACS.  All
input is available in the editor for re-editing and re-submission, and all
output is available for editing.  This facility has been useful in the E
editor on WAITS but requires substantial expansion.  Our experience has
shown us that if the editor provides good enough interactive facilities,
then many user programs can rely on them thus allowing simpler programming
of interactive programs.

%3Character Set.%1 It is time to allow the user arbitrary character sets.  This
presents no difficulty for the internal operation of editors, and only
requires that they admit and recognize that some characters are
represented by multiple bytes.  Similarly bit map displays (IBMese APA
displays) allow the display of arbitrary characters, but keyboards present
a problem for which we intend to provide and explore a variety of
solutions.  The editor will be constructed in such a way that it will be
possible to add graphical constructs such as line drawings and textured
areas, though these features will likely not be included in the initial
implementation.

Our planned solution to the arbitrary character set problem will allow
both for standard keyboards and for keyboards adapted to special tasks,
e.g. the use of mathematics, APL or foreign languages.  Thus a special
character can appear on the screen either because the user has pressed a
key on a special keyboard or because he has pressed a suitable sequence of
keys on an ordinary keyboard.  The same sequence of bytes will inhabit the
file in either case.

%3Configuration.%1 EBOS will take advantage of large memories; we are quite
prepared to make a system that won't run with less than 4 megabytes if
that will make the system run faster and more smoothly.  The basic
technique is to keep large amounts of directory information in main memory
while the system is running.  If a user's command refers to certain files,
our goal is that the only disk operations executed are those that read and
write those specific files.

%3Efficiency.%1 The system will be designed to be efficient with very large
numbers of files and with very large files.  If a reader wishes to treat a
book as a single file, that should work efficiently.

(It is our opinion that paging has basically failed in its goal of making
small memories look like large ones.  It is useful mainly as a means of
address translation, and introduces inefficiencies even when used for
that.  The fastest computers, i.e. the Crays, don't use it.  However, it
looks like EBOS will be implemented on computers that have paging, so
we'll have to minimize the effects of its inefficiencies.  The same
remarks apply to a lesser degree to caches.  In the long run it will
probably turn out that memory hierarchies are more efficiently handled by
compiled software than by built-in hardware features.)

%3Process Linkage.%1 The system will permit processes with multiple inputs and
outputs to be linked together to accomplish a given task.  The user
will be able to monitor and control the process network.

.cb Initial Implementation

We plan to put together an experimental system based on the ideas outlined
above using an existing workstation running Unix.  A new shell, including the
proposed display editor, and a number of utility programs must be written.
The emphasis will be on getting the interactive qualities of the system
right in the first implementation rather than on optimizing performance.

If the initial implementation is successful, it likely will be desirable
to do a deeper reimplementation, including a complete new operating
system, that emphasizes processing efficiency.  Toward this end, we plan
to structure the interfaces between the programs that we write and the
Unix environment so that it will be possible to embed our programs in the
new environment without having to completely rewrite them.

.area text lines 4 to height;
.next page;
.begin center
%3Budget

%1Stanford University proposal to IBM
for
Editor-based Operating System Demonstration
.end
.nofill
.tabs (width - width/4);
.turn on "\";

Nine months beginning 1 September 1986.

→%3Three Months:\ →Six Months:%1
→1 Sep. '86-\  →1 Jan. '87-
→31 Dec. '86\ →30 June '87
Personnel
    Prof. John McCarthy, Principal Investigator	→n/c\ →n/c

    Tepper, Stephan, Res. Programmer (100α%) →9,500\ →19,000

    -----, Student Research Assistant		        →5,418
		(50α% beginning 1 Jan. '87)

    -----, Secretary (5α% time)			  →261\ →522
					      →---------\ →--------
	Salary subtotals		       →9,761\  →24,940

	Allowance for salary increases		→781\  →1,995
	  (8α% beginning 9/1/86)
					      →---------\ →--------
	Salary totals			       →10,542\ →26,935

	Staff benefits (25.1α%)		      →2,646\  →6,761

    Travel (2 East Coast trips. @ $1000)	→2,000

    Computer time costs				→1,000\ →2,000

    Other direct costs				→263\  →2,000
					      →---------\ →--------
	Subtotal			       →14,451\ →39,696

    Indirect costs (73α% of direct costs)       →10,549\ →28,978
      					      →======\ →======
    Totals				    →$ 25,000\ →$ 68,674
							→======
    Grand Total						→$ 93,674